1. Field of the Invention
The present invention relates to distributed applications running in networked computer systems. In particular, the present invention relates to method and system for minimizing database related network traffic in such systems.
2. Description and Disadvantages of Prior Art
The subject matter of the present invention is applicable to a broad variety of applications, i.e. whenever an application has a distributed nature and when data storages are commonly accessed by a plurality of workstations hosting some copy of said distributed application and are distributed in the network. Further, workflow management systems, referred to herein as WFMSs are preferred objects for being subjected to the improvements of the present invention. But basically, every system that can be described with the basic structure and terminology of WFMSs, can advantageously be improved by applying the method according to the invention. For clear terminology and improved clarity the present invention will be disclosed herein in detail as applied to WFMSs and with the terminology of relational database systems by way of example only.
A new area of technology with increasing importance is the domain of Workflow-Management-Systems (WFMSs). WFMSa, as for example implemented by the IBM product FlowMark, support the modeling and execution of business processes. Business processes control which piece of work of a network of pieces of work will be performed by whom and which resources are exploited for this work, i.e. a business process describes how an enterprise will achieve its business goals. The individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.
The process of designing, developing and manufacturing a new product and the process of changing or adapting an existing product presents many challenges to product managers and engineers to bring the product to market for the least cost and within schedule, while maintaining or even increasing product quality. Many companies are realizing that the conventional product design process is not satisfactory to meet these needs. They require early involvement of manufacturing engineering, cost engineering, logistic planning, procurement, manufacturing, service and support with the design effort. Furthermore, they require planning and control of product data through design, release, and manufacturing.
The correct and efficient execution of business processes within a company, e. g. development or production processes, is of enormous importance for a company and has significant influence on company""s overall success in the market place. Therefore, those processes have to be regarded as similar to technology processes and have to be tested, optimized and monitored. The management of such processes is usually performed and supported by a computer based process or workflow management system.
In D. J. Spoon: xe2x80x9cProject Management Environmentxe2x80x9d, IBM Technical Disclosure Bulletin, Vol. 32, No. 9A, February 1990, pages 250 to 254, a process management environment is described including an operating environment, data elements, and application functions and processes.
In R. T. Marshak: xe2x80x9cIBM""s FlowMark, Object-Oriented Workflow for Mission-Critical Applicationsxe2x80x9d, Workgroup Computing Report (USA), Vol. 17, No. 5, 1994, page 3 to 13, the object character of IBM FlowMark as a client/server product built on a true object model targeted for mission-critical production process application development and deployment is described.
In H. A. Inniss and J. H. Sheridan: xe2x80x9cWorkflow Management Based on an Object-Oriented Paradigmxe2x80x9d, IBM Technical Disclosure Bulletin, Vol. 37, No. 3, March 1994, page 185, other aspects of object-oriented modeling on customization and changes are described.
In F. Leymann and D. Roller: xe2x80x9cBusiness Process Management with FlowMarkxe2x80x9d, Digest of papers, Cat. No. 94CH3414-0, Spring COMPCON 94, 1994, pages 230 to 234, the state-of-the-art computer process management tool IBM FlowMark is described. The meta model of IBM FlowMark is presented as well as the implementation of IBM FlowMark. The possibilities of IBM FlowMark for modeling of business processes as well as their execution are discussed. The product IBM FlowMark is available for different computer platforms and documentation for IBM FlowMark is available in every IBM branch.
In F. Leymann: xe2x80x9cA meta model to support the modeling and execution of processesxe2x80x9d, Proceedings of the 11th European Meeting on Cybernetics and System Research EMCR92, Vienna, Austria, April 21 to 24, 1992, World Scientific 1992, pages 287 to 294, a meta model for controlling business processes is presented and discussed in detail.
The xe2x80x9cIBM FlowMark for OS/2xe2x80x9d,document number GH 19-8215-01, IBM Corporation, 1994, available in every IBM sales office, represents a typical modern, sophisticated, and powerful workflow management system. It supports the modeling of business processes as a network of activities; refer for instance to xe2x80x9cModeling Workflowxe2x80x9d, document number SH 19-8241, IBM Corporation, 1996. Further information on Workflow Management Systems available from IBM is contained in: IBM MQSeries Concepts and Architecture, document number GH 12-6285; IBM MQSeries Getting Started with Buildtime, document number SH 12-6286; IBM MQSeries Getting Started with Runtime, document number SH 12-6287. A process model is constructed as a directed, acyclic, weighted, colored graph. The nodes of the graph represent the activities or work items which are performed. The edges of the graph, the control connectors, describe the potential sequence of execution of the activities. Definition of the process graph is via the IBM FlowMark Definition Language (FDL) or the built-in graphical editor. The runtime component of the workflow manager interprets the process graph and distributes the execution of activities to the right person at the right place, e.g. by assigning tasks to a work list according to a respective person, wherein said work list is stored as digital data within said workflow or process management computer system.
In F. Leymann and W. Altenhuber: xe2x80x9cManaging business processes as an information resourcexe2x80x9d, IBM Systems Journal, Vol. 32(2), 1994, the mathematical theory underlying the IBM FlowMark product is described.
In D. Roller: xe2x80x9cVerifikation von Workflows in IBM FlowMarkxe2x80x9d, in J. Becker und G. Vossen (Hrsg.): xe2x80x9cGeschaeftsprozessmodellierung und Workflowsxe2x80x9d, International Thompson Publishing, 1995, the requirement and possibility of the verification of workflows is described. Furthermore, the feature of graphical animation for verification of the process logic is presented as it is implemented within the IBM FlowMark product.
For implementing a computer based process management system, firstly the business processes have to be analyzed and, as the result of this analysis, a process model has to be constructed as a network of activities corresponding to the business process. In the IBM FlowMark product, the process models are not transformed into an executable. At runtime, an instance of the process is created from the process model; this is called a process instance. This process instance is then interpreted dynamically by the IBM FlowMark product.
A user typically interacts with the workflow management system via a graphical end user interface that represents the tasks to be performed by the user as icons. Work for a particular task is started by the user by double-clicking on the appropriate icon, which in turn starts the program implementing the activity.
It is important for the productivity of the user that the program complete its access to data as fast as possible to avoid delays in interacting with the user. In many cases WFMSs are executed by a multitude of distributed computer systems accessing resources/objects that also are spread across the computer network. In such distributed environment, a user who controls execution of an activity assigned as a work item to him or her could suffer sever performance degradations until the system has been able to provide all the required resources/objects. The problem becomes even worse if the activity has to access large resources/objects or if the activity requires access to a large number of resources/objects distributed across a large number of different computer systems.
Considering now aspects closer to the focus of the present invention, WFMSs, as for example implemented by IBM FlowMark, are characterized by the fact that activities within the application may be executed on different computer systems in the network. Such different systems can include systems with different operating systems.
The activities to be performed have typically a fine structure:
An Activation Condition defines when the activity is ready for scheduling by the workflow manager; an Exit Condition defines when an activity should be treated as complete by the workflow manager. The core of the activity is the Task which is comprised of the proper activity and a query on an organization database. The Proper Activity associates the activity with a program object. The program object defines for each operating system, and possibly for each user, the name and operational characteristics of an executable piece of software. The executable piece of software is started when the activity is performed by a user. The query on the organization database defines the persons responsible for performing the activity. When the activity is ready to be scheduled, the workflow management executes the specified query against the organization database. This query returns a set of persons, to which the activity is assigned. The task is transformed into a set of work items, one for each person selected as the result of the query against the organization database. A work item contains the name of the person responsible for its completion and the program to be executed. These work items are made part of the users"" worklist.
Each of the activities is performed by an activity implementation. The activity implementations are typically programs, but they may also be invocations of method objects or stored procedures in a relational data base.
The results produced by the work represented with an activity is put into an output container, which is associated with each activity. Since an activity will, in general, require access to output containers of other activities, each activity may also be associated with an input container. At runtime, the actual values for the formal parameters building the input container of an activity represent the actual context of an instance of the activity. Each data container is defined by a data structure. A data structure is an ordered list of variables, called members, that have a name and a data type. Data connectors represent the transfer of data from output containers to input containers. When a data connector joins an output container with an input container, and the data structures of the two containers match exactly, the FlowMark workflow manager maps the data automatically.
The data accessed by the activity implementations may be data which is specific to one particular activity implementation or it may be data which is shared between different activity implementations. Processes are typically associated with a set of business objects; thus sharing data is the typical case. As these business objects are often made persistent in relational databases, relational database terminology is used herein to describe the access of activity implementations to data. Nevertheless, any other persistent data storage mechanism could be used instead.
The different activities of a process are executed by different users working on different workstations that may be attached to different servers. The activity implementations are executed either solely on the user""s workstation or on the associated server in case of a client/server application. Regardless of where the activity is implemented, it requires that some, possibly all, activity implementations need to access data using some network connectivity.
Consequently, a large network traffic develops when a complex business process is executed. The network traffic consists in a large number of data flows between a plurality of nodes in the network. Large network traffic, however, results in longer response times to the user and possibly in a corresponding safety risk implied by the transport of data through the network.
To handle this problem, data streams are compressed and encrypted. The amount of network traffic, however, is still large.
Therefore, an object of the present invention is to provide a method for minimizing the database related network traffic caused by distributed applications running in networked computer systems accessing distributed data.
The object of the invention is achieved by the features stated in the independent claims. Further advantageous arrangements and embodiments of the invention are set forth in the respective dependent claims.
A method for minimizing network traffic of distributed applications is proposed. The method operates in a distributed environment in a networked computer system comprising a plurality of workstations and a plurality of database management systems (DBMS). The DBMSs manage data in a set of tables for use by the workstations. Workflow between the tables and other system parameters are used to derive from process models a placement of tables that results in minimal network traffic when the process model is executed. The network traffic is minimized by choosing the locations of data storages, and in particular the locations of data base tables such that the overall network traffic in and out of these data base tables is minimized.
The method of the present invention with the characteristics of claim 1 has the advantage, in relation to the method sketched out in the discussion of prior art technique, that the network traffic is minimized. Consequently, the average response time is lowered and costs are reduced.
In a preferred embodiment of the invention as set forth in claim 2 the method is applied to WFMSs. This extends the advantages mentioned above for those systems.
In a preferred embodiment of the invention as set forth in claim 3, traffic is calculated including number and type of database calls for each activity and the locations where the activities are executed is determined. This is a systematic means for determining how to minimize the workflow. Thus, the advantages mentioned above are further enhanced.